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The invention tela.es to a system for handling data 

D a,a is used in business and technology to ptov.de for a variety of needs, for example 
ailing of business pe,— Previous attempt, at — in,.— n a 

sur vey based apptoaob ***** *- -» P"**— «»«** 2 " * ™ 
onnaites Tbe results of Ihese q ues t ,„n„rcs ate then analysed fo, trend, , « 
aclc ,0 participants. Such approaches bavc assorted proHems, for -np h a 

wp cnsJe, tnna.consu.in, and prone ,0 error as data can be misused, m.sallocated or 

simply overlooked. 

„ is an ob,cc, of tbe inventton to seek to mitigate these disadvantages. 

A ccord,n S to the invention there is prov.ded a system for providing an 
coming means ,o ass„n.,a,e s,a„c data, means to prov.de mapping of and 
Used structure of sa,d data as a summary report, .hereby to prov.de a, enhanced 
analysis of said data. 

^ r^nnrt This orovides an enhanced analysis 
The summary report may compnse a one page repo.t. rh.s prov.oes 

and allows d.rect use of the system in business management. 

The system may be a computer-based system and the means ,0 assimilate data may 
comp ,L a data base and graph.cal use, interface whereby to normal.se stat.c data mpu 
This is parucularly advantageous, . particularly where me graph.ca, user .nterf.ee may 
comprise drag and drop means whereby to display a normalised structure. 

The means ,0 provide mapping nay emprise a means to map static da. into the system. 
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There may suitably be mans to translate sa.d static data and balances into the system. 

There may also be sign off means adapted to define a normalisation process, for example 
sign off sheet categor.es, which may be adapted to group input data and to replay said 
data for formal sign off. 

There may also be dictionary means adapted to relate to nodal points of a structure, and 
include and/or exclude data related to d lS cretc nodal points. 

The sa ld data may comprise produces) and/or serves) related to or associated wuh a 
terete nodal poinl. It will be understood that a nodal point may be a cost centre of a 
business. 

There may be a relational data base management system and a visual front end system, 
and the first mentioned system above may be at least part of the means to assimilate stake 
data and may comprise a plurality of discrete store tables for data. . 

The store tables may comprise respectively tables to store source data, standardised 
structures and definitions, translated data, benchmarking results and/or allocations and 
security and/or audit functions. 

The visual front end system may be adapted to manipulate data of the related data base 
management system. 

The visual front end system may also comprise respective means for loading data, 
manipulation of standardised structures and definitions, mapping, translation of data into 
standardised format, calculation of results, reporting and administration. 
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The means for loading data may compr.se means for handling data composing staric data, 
reporting structure, balance and metric data. 

The means for administration may comprise means for providing security and/or audit 
trail facilitation. 



The system may 
banking. 



be adapted for benchmarking of a business, for example investment 



Using the invention U is possible to provide a high level summary of busmess results 
which can be used the better to target scarce resources at business change, which can be 
complemented by detailed reports for each node, or area, of a business. The methodology 
may incorporate a front water fall and a set of standard metr.es. 

A system for embodying the invention is hereinafter described, by way of example, with 
reference to the accompanying drawings. 

Fig. 1 is a graphical representation of a system according to the invention, 

Fig. 2 is a representation of a sample screen, 

Figs. 3 and 4 show respectively detailed screens used in the system; 



Fig. 5 shows a screen of balance data; 

Fig 6 shows a Master Business Unit hierarchy scheme; 

Fig. 7 shows a typical mapping screen; 
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Fie. 8 shows an example of a summary report; and 



Fig. 9 shows a single screen report 



Referring to the drawings, there is shown a system which is analysing data results in a 
single screen report which has a single screen I, Fig. 9, which provides a technical 
solution to the problem of handling data concerning all aspects of a business or 
technology, for example investment banking or utilisation of nanotechnology. 

In the following, investment banking is referred to, purely by way of example. 

Fig. I shows a schematic of the main aspects of the system, where a client 2 provides to 
the system 3 various data, for example basic data relating to the scope of the project 4, 
there being a time-line 5, for example week 1 - week 12, for dealing with the input data 
from 2. The system 3 includes for example scope of project 6, initial explanatory 
interview 7, static data collation 8 by appropriate computer related means, normalisation 
and/or mapping 9, sign off reporting 10, calculation of benchmarks 1 1, draft reporting 12, 
and final reporting 13. 

Functions such as items 8, 10, 12 are two way functions between the input 2 and system 
3, by way of iteration as appropriate. 

The means for data load.ng will be enhanced in the system by dealing with a client to 
achieve v,a its staff at 7, a good understand,.^ of data collation and the management 
process al 2. 



The level to be used, medium for transfer, and scope of data will be discussed and agreed 
at the initial project planning sessions, 1,2. 
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The data 



loads are divided into two main categories: static data and balance data. 



Static Data 

Static data consists o ihe atomic level data: 

• Cost Centres 

• Accounts 

• Locations 

In addition to this base level data respective hierarchies are utilised to assist with the 
mapping process. 

Where a client 2 does not have a gloval General Ledger, each of the regional GL's (or 
equivalent) will need to be loaded 

Any electronic format can be taken but the client 2 is encouraged to follow the guidelines 
outlined in a Data Take-on document to minimise inconsistencies. Tn the sample screen 
14 (Fig. 2) the cost centre static has been provided in comma delimited text file format. 

In addition to the cost centre, account and location static, information on headcount, 
headcount grades, and trade count will be gathered and included in the system. 

Once the slatic data and hierarchies have been loaded into the system 3, analysts at 3 may 
start reviewing the data. Alternate hierarchies may be loaded if they exist, as shown in 
scieen 15, Fig. 3, where a particular node 16 is shown highlighted. 

The next state in the system 2 is to categorise the client's static data into high-level 
summary groupings e.g. Equities, Fixed Income, IT, Finance etc. These groupings, called 
sign-off sheet categories/are used during the sign-off process. The screen 17 shown in 
Fig. 4 relates to cost centre groupings categorised . . . „ , 



Balance Data 



Year-end balances, which include some or all of the following as relevant, are loaded by 
cost centre, account and location, e.g. 



Direct costs 
Allocated costs 
Front Office Allocations 
Bonus 

Contra Revenue 
Revenue 



Headcount data is loaded by cost centre and location and includes: 

• Year-end headcount - full time employees and contractors 

• Average/monthly headcount - full time employees and contractors 
9 Headcount by grade including contractors 

Average/monthly headcount is captured to facilitate analysis of staff turnover during the 
year 

Trade count is loaded at a later stage at sub-producl level. 

Once all balance data is loaded, a High Level Dataload Reconciliation report is produced 
using high level groupings ("sign-off sheet categories"). The high level numbers reconcile 
to the client's 2 financial statements and the client 2 agrees both the cost centre and 
account groupings, as shown on screen 1 8, Fig. 5, 
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Normalisation/Mapping 

To ensure a correct comparison, the system maps the cheat's static (accounts, cost 
centres, and locaUons) into respective master structures Such master structures are mu.t. 
tiered structures that allow report.ng at varying levels of granularity. 

Ghent data 2 is mapped to the lowest level possible. Analysis ,s normally provided at the 
business unit level however where granularity ex.sts at the lower levels, for all client* 
this can be analysed. 

For business units the system tracks from desk or support area up through to div.sion, as 
shown for screen 19 (Fig. 6) which is an extract of a Master Business Unit hierarchy. 

Each node in the master structure is defined in terms of what is included and what is 
excluded. This helps ensure consistency between mappings. 

Mapping Process 

The client 2 h.erarchies are used in the system in the mapping process. Where these 
hierarchies do not provide sufficient information or there is any ambiguity on the nature 
of the costs, clarification is obtained from the client at 2. 

Balances and headcount numbers are available during the mapping process. These 
balances help eliminate defunct or immaterial static quickly. 

A typical mapping screen 20 is shown in Fig. 7, which shows a target hierarchy 21, client 
selected node hierarchy 22 and client 2 source hierarchy 23 . 
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The mapping process is an iterative process involving the client to ensure mappings are 
appropriate and understood. 

Sign-Off Process 

Once the mapping process is complete, a series of summary and detailed audit reports are 
produced for the cl.ent 2 to sign-off 10. A separate report is produced for each of the high 
level groupings ("sign-off sheet categories"). An example headcount summary report for 
Equities is shown at 24, Fig. 8. 

The audit reports identify three different sections 

Section A includes those cost centres that both the client 2 and system define as 
the same i.e. in this example Equities. 

Section B includes those centres that the client defines as Equities but that the 
system defines as nun-Equities. E.g. Equities Product Control - mapped to Finance by the 
system. 

Section C includes those centres that the client defines as non-Equit.es and the 
system defines as Equit.es E.g. Equity Derivatives - cl.ent 2 includes in Fixed Income. 

Benchmark Calculation & Reporting 

Once all the clients have signed off die. Benchmark calculations are triggered. The 
system performs various control checks and reviews on (he numbers following, which 
draft reports are produced. The draft reports 12 are sent to the clients 2 for review. If any 
discrepances are found that require mapping changes, the Benchmarks are recalculated, 
the process starts again. Once all clients have reviewed the draft reports and are happy 
with the numbers, final reports 12 are produced with a management summary that 



9 



includes the system's key findings and observations on the results. These are produced on 
a single screen 1. 

Using the rnvention it is possible to provrde an analysis of a business which comprises 
two mam pals, a relational database management system (ROMS) and a visual baarc 
front-end, 

The database structure within RDMS has been developed after careful analysis of system 
requirements and has been updated through various iterations being formed of a number 
of tables used by the system to store the following- 

• Participant source data i.e. static structures, balances, metrics etc 

• Standardised structures and definitions 

• Translated participant data 

• Benchmarking results including allocations 

• Security and audit related 

The visual basic front-end has been developed for manipulating the data within the 
RDMS database It provides a range of functions that include: 

Loading of participant data i.e. static, reporting structures, balance and metric data 
Manipulation of the standardised structures and definitions 
Mapping process 

Translation of participant data into standardised format 
Calculation of benchmark results including allocations 
Reporting. 

Administration functions e.g. security, audit trails etc, 



